Sensor and actuator networks are deployed to affect the environment they are placed in based on events. A sensor monitors the physical environment. Information collected by the sensor is injected in the virtual world, processed and acted upon. Typically, acting upon monitoring information coming from sensors involves triggering an actuator, which will again impact the physical environment. For example, in a wireless home automation system pressing a button should trigger the light, where the button is an example of a sensor capturing the action of a user and where the light is an example of an actuator enabling power supply to the actual light source. Another straightforward example is the interaction between a temperature monitoring system and the heating/ventilation system.
In the past, most systems were closed proprietary systems that could only be interacted with through predefined user interfaces, leaving no room for customization or combinations with other systems. More recently, various devices, deployed as a network of nodes, have become useful for collecting and/or processing data in applications such as ambient intelligence, smart environments, and autonomous control. For example, networked sensors may be deployed in a building to measure the temperature and humidity such that an air conditioning system for the building may be adjusted autonomously. These networked devices generally comprise constrained nodes or constrained devices in a (constrained) network, where the term “constrained” is used to express presence of limitations in terms of, e.g., power and/or computing resources.
With the advent of technologies such as 6LoWPAN and Constrained Application Protocol (CoAP), these nodes have become easily accessible over the Internet, where each node is uniquely identifiable and where the nodes act as servers to which clients can connect. Such a system of server nodes is sometimes referred to colloquially as “Internet of Things” and the networks that connect these server nodes may be low power and lossy networks (LLNs). A client may be configured to access a server node through a server-client relationship, using the CoAP protocol. Typically, each of the server nodes has at least one resource that provides and/or processes specific information and can be identified by a uniform resource identifier (URI). Usually, the resource that provides specific information comprises a sensor resource while the resource that processes specific information and acts on it comprises an actuator resource. Examples of the kind of specific information provided and/or processed via the resource include temperature, humidity, room location, picture, or light control. When a client accesses a server node, it may e.g. query the server node for the resource at the node. For example, using the (conditional) observe option of the CoAP protocol in a GET request it is possible for a client to observe a resource on a sensor (e.g. sensor values such as e.g. the current temperature, the state of a light switch, the value of a parameter, etc.) and to receive notifications of interest. An actuator resource may process information received via a PUT/POST request on the resource (e.g. payload “1” means turning the light on, payload “0” means turning the light off, the desired temperature is provided to a smart thermostat, the value of a parameter is set, etc.).
While initiatives like 6LoWPAN and CoAP are making sensor networks more and more accessible to the outside world and give end users new opportunities to directly interact with these constrained devices, even with these open standards, the creation of interactions between sensors and actuators, referred to as “binding”, is mostly under control of a third party. The third party, typically a gateway or a Cloud service, then both manages the collection of sensor events and the generation of corresponding triggers destined for actuators.
In view of the “real” IoT, where everything is connected to the Internet and everything can interact with everything, such involvement of a third party has a number of drawbacks. One drawback is that many users would like to have the possibility of initiating and controlling sensing and actuation from any device or any network. An example use case could be using a smart phone to change the settings of a home heating system. Another example could be a user at the gateway of an environmental monitoring system associating a sensor to send information to specific actuators to take action. Another drawback is that the third party needs to be available at all times and needs to offer all of the required functionality to establish bindings between the devices. Additionally, since all interactions take place via this third party, all traffic is routed via the third party. In some cases this can result in unnecessary traffic or increased latencies in the network.
Direct bindings, where the sensor directly triggers the actuator, could provide an alternative. However, at this moment, no generic solutions to realize such direct interactions exist. For example, one can (re)program the sensor and/or actuator in order to link them together. However this approach is cumbersome and not flexible. Other solutions to link two devices together can be realized via pairing (e.g. bringing a light switch in the proximity of the light it needs to control and starting a pairing procedure). This works at installation time, but it is much more difficult to update these bindings or create more advanced bindings.
What is needed in the art is a mechanism for binding smart objects that overcomes one or more drawbacks described above. In particular, there is a need in the art for improved methods and systems that enable such binding by a software program.